BLUEPRINT

3 버전 진화 로드맵

제3장: 버전 진화 로드맵

본 장에서는 CAP 프로토콜의 버전 진화 로드맵을 정의하고, v1 버전의 기능 범위와 제외 항목을 명확히 하며, 버전 번호 명명 규칙과 호환성 정책을 수립하고, 초안에서 정식 버전까지의 릴리스 프로세스를 기술한다. 버전 로드맵은 프로토콜의 반복적 개발과 커뮤니티 협업을 위한 명확한 경로 지침을 제공한다.

3.1 v1 버전 기능 범위

CAP 프로토콜 v1 버전은 완전한 단말 제어 권한 관리 기본 프레임워크 구축에 집중하며, 다음 6가지 핵심 능력을 포함한다:

  1. 오프라인 인가(Authorization_Descriptor): v1 버전의 핵심 메커니즘. Authorization_Descriptor의 완전한 생명주기 관리를 구현하며, 발급, 로컬 저장, 검증, 폐기 및 갱신을 포함한다. 단말은 오프라인 상태에서 로컬에 저장된 Authorization_Descriptor를 통해 독립적으로 인가 검증을 완료하여 네트워크 없는 환경에서 Fay의 기본 가용성을 보장한다. v1 버전은 완전한 신뢰 체인 모델과 로컬 폐기 목록 메커니즘을 구현한다.

  2. 온라인 티켓(Trusted_Ticket): v1 버전의 보완 메커니즘. 네트워크 연결 환경에서의 실시간 인가 발급 및 폐기 상태 조회 기능을 구현하고, Trusted_Ticket에서 로컬 Authorization_Descriptor 형식으로의 변환 및 온라인에서 오프라인으로의 원활한 저하 정책을 지원한다. v1 버전은 온라인 티켓과 오프라인 인가 간의 협업을 보장한다.

  3. 세션 관리(Session lifecycle): 제어 세션의 완전한 생명주기 관리를 구현하며, 생성, 활성 및 종료의 세 단계를 포괄한다. v1 버전은 Session과 Terminal_Resource의 일대일 바인딩 관계를 지원하고, 능동적 해제, 타임아웃 종료 및 폐기 종료의 세 가지 세션 종료 방식을 구현한다.

  4. 제어권 인계 정책(Handover_Policy): 다중 제어자 간의 제어권 이전 기능을 구현하며, Fay 간 및 Fay와 인간 사용자 간의 인계 시나리오를 포괄한다. v1 버전은 세 가지 정책 유형(우선순위 규칙 스크립트, AI 모델 실시간 판정, 인간 사용자 결정)을 지원하고, 인계 과정의 원자성을 보장하며, 타임아웃 롤백 메커니즘을 구현한다.

  5. 생존 감지(Liveness_Detection): 장기 연결과 애플리케이션 계층 하트비트를 결합한 세션 생존 감지 메커니즘을 구현한다. v1 버전은 이중 판정 로직(장기 연결 단절과 하트비트 타임아웃 동시 충족)을 지원하고, 구성 가능한 하트비트 간격과 타임아웃 임계값, 그리고 실효 세션의 자동 종료 및 자원 회수를 지원한다.

  6. 자원 접근 모드(Resource_Access_Mode): 작업 유형에 따른 자원 접근 등급 관리를 구현하며, read, write, execute, configure의 네 가지 접근 모드를 지원한다. v1 버전은 완전한 읽기-쓰기 잠금 모델을 구현하고, read 모드의 다자간 동시 접근과 write, execute, configure 모드의 배타적 제어를 지원한다.

이상 6가지 핵심 능력이 v1 버전의 완전한 기능 세트를 구성하며, iFay 체계에서 지능형 에이전트가 단말을 안전하게 인수하기 위한 기본적인 제어 권한 프레임워크를 제공한다.

3.2 v1에서 명시적으로 제외된 기능

다음 기능은 v1 버전에 명시적으로 포함되지 않으며, 향후 버전의 후보 항목으로 표시된다:

제외 기능설명후보 버전
크로스 단말 세션 마이그레이션활성 Session을 한 단말에서 다른 단말로 마이그레이션하여 세션 상태의 연속성을 유지v2+
다중 단말 협업 인가여러 단말 간의 인가 상태 동기화 및 협업 검증 메커니즘v2+
인가 위임 체인(Delegation Chain)Fay가 자신이 획득한 부분적 인가를 다른 Fay에게 위임하는 계단식 인가 메커니즘v2+
세분화된 자원 접근 제어(ABAC)속성 기반 접근 제어 정책으로, 더 복잡한 자원 접근 조건 표현을 지원v2+
감사 로그 표준화 형식통일된 감사 로그(Audit_Logger) 출력 형식 및 조회 인터페이스 규격v2+
프로토콜 메시지 암호화 전송 규격CAP 프로토콜 메시지의 네트워크 전송 계층 암호화 방식 및 키 협상 프로세스의 표준화 정의v2+
오프라인 인가의 분산 폐기 합의여러 단말 간에 오프라인 환경에서 폐기 상태에 대한 합의를 달성하는 메커니즘v3+
동적 권한 상승(Session 내)활성 Session 생명주기 내에서 새로운 Session을 생성하지 않고 접근 권한을 동적으로 상승v3+

v1 버전은 "기반을 먼저 구축하고 능력을 확장한다"는 원칙을 따르며, 6가지 핵심 능력의 완전성과 안정성을 우선 보장하고 고급 기능은 후속 버전 반복에 남겨둔다.

3.3 버전 번호 명명 규칙과 호환성 정책

버전 번호 명명 규칙

CAP 프로토콜은 시맨틱 버전 관리(Semantic Versioning) 형식을 채택한다: MAJOR.MINOR.PATCH

  • MAJOR(주 버전 번호): 프로토콜에 하위 호환되지 않는 중대한 변경이 발생할 때 증가한다. 예를 들어 핵심 메시지 형식의 구조적 조정, 인가 검증 프로세스의 근본적 변경 등이다. 주 버전 번호 변경은 기존 구현이 적응 수정을 수행해야 함을 의미한다
  • MINOR(부 버전 번호): 프로토콜에 하위 호환되는 기능이나 능력이 추가될 때 증가한다. 예를 들어 새로운 자원 접근 모드 추가, Handover_Policy의 정책 유형 확장 등이다. 부 버전 번호 변경은 기존 구현의 정상 운영에 영향을 미치지 않는다
  • PATCH(수정 번호): 프로토콜에 하위 호환되는 오류 수정이나 문서 명확화가 수행될 때 증가한다. 예를 들어 규격 문서의 모호한 기술 수정, 경계 상황 처리 설명 보충 등이다

초안 버전은 draft 식별자를 사용하며, 버전 번호를 부여하지 않는다. 초안 버전은 어떠한 호환성도 보장하지 않으며, 언제든지 파괴적 변경을 수행할 수 있다.

정식 릴리스 버전 번호 예시: 1.0.0, 1.1.0, 1.1.1, 2.0.0

호환성 정책

CAP 프로토콜의 호환성 정책은 다음 원칙을 따른다:

  • 동일 주 버전 내 하위 호환: 동일 MAJOR 버전 내에서 새 버전의 프로토콜 구현은 이전 버전의 프로토콜 메시지를 처리할 수 있어야 한다. 예를 들어, v1.2.0을 구현한 단말은 v1.0.0 형식의 Authorization_Descriptor를 처리할 수 있어야 한다
  • 주 버전 간 호환 미보장: 서로 다른 MAJOR 버전 간에는 하위 호환을 보장하지 않는다. 주 버전 번호가 증가할 때, 프로토콜 규격은 모든 파괴적 변경과 마이그레이션 가이드를 명시적으로 나열한다
  • Schema 버전과 프로토콜 버전 정렬: 각 프로토콜 버전은 하나의 Schema 버전에 대응하며, Schema 파일은 프로토콜 버전 번호로 명명된 디렉토리에 저장된다(예: schema/2025-10-25/). 이를 통해 버전 대응 관계가 명확하고 추적 가능하도록 보장한다
  • 최소 지원 버전 선언: 프로토콜 구현은 지원하는 최소 프로토콜 버전을 선언할 수 있으며, 해당 버전 미만의 프로토콜 메시지는 처리가 거부된다

3.4 초안에서 정식 버전까지의 릴리스 프로세스

CAP 프로토콜의 초안에서 정식 버전까지의 릴리스는 다음 프로세스를 따른다:

단계 1: 초안(Draft)

  • 프로토콜 규격과 Schema 정의는 draft/ 디렉토리에 저장된다(예: schema/draft/, specification/draft/)
  • 초안 단계에서는 빈번한 파괴적 변경이 허용되며, 호환성을 보장하지 않는다
  • 초안 내용은 커뮤니티 피드백과 리뷰를 수용하며 지속적으로 반복 최적화된다
  • 초안 단계의 문서와 Schema는 언제든지 업데이트할 수 있으며, 버전 번호 증가 규칙을 따를 필요가 없다

단계 2: 릴리스 후보(Release Candidate)

  • 초안 내용이 안정화되면 릴리스 후보 단계에 진입한다
  • 릴리스 후보 버전은 -rc.N 접미사를 사용하여 식별한다(예: 1.0.0-rc.1)
  • 릴리스 후보 단계에서는 오류 수정과 문서 명확화만 수용하며, 새로운 기능은 수용하지 않는다
  • 릴리스 후보 버전은 Schema 검증, 다국어 문서 구조 등가성 검사 및 속성 테스트를 포함한 완전한 테스트 검증을 통과해야 한다

단계 3: 정식 릴리스(Release)

  • 릴리스 후보 버전이 충분한 검증을 거친 후, -rc.N 접미사를 제거하여 정식 버전이 된다
  • 정식 버전의 프로토콜 규격과 Schema 정의는 draft/ 디렉토리에서 버전 날짜로 명명된 디렉토리로 복사된다(예: schema/2025-10-25/)
  • 정식 버전 릴리스 후, 해당 버전의 프로토콜 규격과 Schema 정의는 더 이상 수정되지 않으며(immutable), 모든 변경은 새 버전 릴리스를 통해 이루어진다
  • 정식 버전 릴리스 시, 9개 언어의 블루프린트 문서와 프로토콜 규격이 동시에 완성되고 구조 등가성 검증을 통과해야 한다

단계 4: 유지보수(Maintenance)

  • 정식 버전 릴리스 후 유지보수 단계에 진입하며, PATCH 수준의 오류 수정만 수용한다
  • 새로운 MAJOR 또는 MINOR 버전이 릴리스된 후, 이전 버전은 제한적 유지보수 기간에 진입하며 최종적으로 폐기(deprecated)로 표시된다
  • 폐기된 버전의 문서와 Schema 정의는 역사적 참조를 위해 저장소에 보존되지만, 더 이상 어떠한 업데이트도 수용하지 않는다